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(57) A method and system that reduces the ROM 
space allocated for internal data structures by a runtime 
engine (such as the Java virtual machine). The internal 
data structures store member information for preloaded 
classes used by applications executed by the runtime 
engine. The system determines the different types of in- 
ternal data structures represented in the classes and 
identifies the possible values of each type's members. 
The system next determines the amount of space re- 
quired to store the values for each type in a respective 



value table and the number of bits needed to index each 
entry of that table. The system determines based on the 
stored information whether occurrences of a member 
are optimally represented as a set of value table indices 
and a value table or, in the conventional manner, as a 
general variable that stores the member's value for each 
occurrence. This determination is based on the size of 
the general variable, the number of occurrences of the 
member, the memory needed for each index and the 
size of the value table. 
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Description 

[0001] The present invention relates generally to a class preloader and, particularly, to a system and method for 
reducing the size in read only memory of preloaded Java classes. 

BACKGROUND OF THE INVENTION 

r00021 A Java program comprises a number of small software components called classes. Each class contains code 
and data and is defined by information in a respective class file. Each class file is organized according to the same 
platform-independent "class file format'. Referring to FIG. 1 , there is shown a block diagram of the class file format, 
according to which each class file 400 includes header information 402, a constant pool 404, a methods table 406 and 
a fields table 408 The header information 402 identifies the class file format, the size of the constant pool, the number 
of methods in the methods table 406 and the number of fields in the fields table 408. The constant pool 404 is a table 
of structures representing various string constants, class names, field names and other constants that are referred to 
within the class file structure and its sub-structures. The methods table 406 includes one or more method structures, 
each of which gives a complete description of and Java code for a method explicitly declared by the class. The fields 
table 408 includes one or more field structures, each of which gives a complete description of a field declared by the 
class An example of the fields table 408 is now described in reference to FIG 1 B. 

[0003] A Java program is executed on a computer containing a program called a virtual machine (VM), which is 
responsible for executing the code in Java classes. It is customary for the classes of a Java program to be loaded as 
late in the program's execution as possible: they are loaded on demand from a network server or from a local file 
system when first referenced during the program's execution. The VM locates and loads each class, parses the class 
file format, allocates internal data structures for its various components, and links it in with other already loaded classes. 
This process makes the method code in the class readily executable by the VM. 
2S [0004] For small and embedded systems for which facilities required for class loading, such as a network connection, 
a local file system or other permanent storage, are unavailable, it is desirable to preload the classes into read only 
memory (ROM) One preloading scheme is described in U.S. Patent Application Serial No. 08/655.474 ("A Method 
and System for Loading Classes in Read-Only Memory"), which is entirely incorporated herein by reference. In this 
method and system, the VM data structures representing classes, fields and methods in memory are generated offline 
30 by a class preloader. The preloader output is Ihen linked in a system that includes a VM and placed in read-only 
memory This eliminates the need for storing class files and doing dynamic class loading. 

[0005] Referring to FIG 2A. there is shown a more detailed block diagram of the VM data structures 1 200 generated 
by the class preloader. The data structures 1200 include a class block 1202. a plurality of method blocks 1204. a 
plurality of field blocks 1214 and a constant pool 1224. 
35 [0006] The class block 1 202 is a fixed-size data structure that can include the following information: 

• the class name 1 230; 

• a pointer 1 232 to the class block of the current class's immediate superclass; 

• a pointer 1 234 to the method blocks 1 204; 
40 • a pointer 1236 to the field blocks 1214; and 

• a pointer 1 238 to the class' constant pool; 

[0007] The elements of a class block data structure are referred to herein as class block members. 
[0008] A method block 1 204 is a fixed-sized data structure that represents one of the class's methods. The elements 
45 of a method block data structure are referred to herein as method block members. A field block 1 21 4 is a fixec^size 
data structure that represents one of the class's instance variables. The elements of a field block data structure are 
referred to herein as field block members. 

[0009] Each type of VM dala structure, including the class block 1 202, method blocks 1 204. field blocks 1 21 4 and 
constant pool 1 224 has a format defined by a corresponding data structure declaration. For example, a single method 
so block declaration defines the format of all method blocks 1 204. The data structure declarations also define accessor 
functions (or macros) that are used by the VM to access data structure members. These data structure declarations 
are internal to the VM and are not used by class components. The prior art data structure declarations are now described 
in reference to FIG. 2B. 

[001 0] Referring to FIG . 2B, there is shown a depiction of data structure declarations 1 230 that define the format of 
55 all data structure types employed by a particular VM. Each declaration 1 230 includes a set of member declarations 
1232 and accessor functions 1234 for accessing respective members. The member declarations 1232 and accessor 
functions 1234 are defined conventionally, according to the syntax of the language used in the implementation of the 
VM For example, assuming the C language is used in the data structure declarations 1 230, a generic field data structure 
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1230.N (shown in FIG. 2B) could be defined as a structure T with five members of the following types with respective 
accessor functions: 





member name member type accessor functions 


5 


memberl 


mtypel 


meml of (T) T-> memberl 




. member2 


mtype2 


mem2 of (T) T->member2 




member3 


mtype3 


mem3 of (T) T->member3 




member4 


mtype4 


mem4 of (T) T->member4 


10 


members 


mtypeS 


mem5 of (T) T->member5 



[0011] In this example, the member types can be any type defined by the relevant computer language, including 
user defined types or language types, such as integer, float, char or double. The. accessor functions are macros used 
by the VM to access the fields without needing to access directly the structure containing the field. For example, instead 
of employing the expression *T->member1 " to access fieldl in structure type T, the VM need only employ the expression 
"meml of (T)*. Accessor functions are well known in programming languages : such as C, that provide sophisticated 
data structure capabilities. 

[0012] The internal data structures used to store "class meta data' (i.e., the class, method and field blocks 1202, 
1204, 1214) require large, fixed amounts of space in read-only memory. In fact, measurements indicate that this sort 
of class meta data often takes up much more space than the bytecodes for the class methods themselves. These 
internal data structures are therefore often unsuitable for use in small, resource-constrained devices in which class 
preloading is desirable and/or necessary. 

[001 3] Moreover, if the internal data structures were individually modified to save memory space, the VM code would 
need to be extensively revised to enable the VM to correctly access the modified data structures. To make such changes 
to the VM could be onerous and inefficient. : 
[0014] Therefore, there is need for a modified representation of the internal data structures that is smaller in size 
than the prior art data structures, includes all information required by the VM, and does not require extensive or onerous 
modification of the VM code. 



30 SUMMARY OF THE INVENTION 



[0015] In summary, the present invention provides a method and system that reduces the ROM space required for 
preloaded Java classes. 

[0016] In particular, the method and system of the present invention are based upon the realization that, in an envi- 
ronment where the Java VM classes are preloaded, it is highly likely that the VM would be a closed system with a set 
number of classes and class components, such as fields and methods. Such a closed VM would include a fixed number 
of internal data structures, such as class blocks, method blocks and field blocks. Moreover, each member of these 
data structures (e.g., a method block or field block member) would have one of a well-known set of distinct values. 
[0017] Given this assumption and its implications, embodiments of the present invention reduce the memory space 
required to represent the internal data structures by: 

1) determining distinct values of each type of data structure member; 

2) determining occurrences of each data structure member type (e.g., each occurrence in the method blocks of a 
field block member type) and each occurrence's value; 

3) determining memory space that would be saved if each occurrence were represented as an index to a table of 
values of the data structure member type rather than conventionally (storing the value for each occurrence in a 
general variable); and 

4) if sufficient savings would result, allocating a value table containing the distinct data structure member type 
values and configuring each occurrence of that field block member type as an index to the appropriate value table 
entry; and 

5) generating new sources to the VM so that its access to the modified structures is adapted automatically. 

[0018] In a preferred embodiment, the decision is made to represent a data structure member type as a value table 
index plus a value table if the following comparison is true: 

(#occurrences of type) x (size of index) + (size of value table) < 

(#occurrences of type) x (size of general variable). 
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[001 9] Once the present method has determined for each data structure member type whether an occurrence of that 
type ,s to be represented as an index into a value table or as a general variable storSg the value " ^S2Tn2S 
s emrts appropnate .nformat.on for that type, including accessor functions, language declarations and XcTcc^f th* 
.nrt.al.zes the value tables. The accessor functions are macros through whicS all runtime accel to thTdata s^ucture 

de ermines the most compact arrangement of the value table indices, conventional representations of me ZI 

10 S^*SL and »7"Z T value ,ables - value ,ab,e indk » s - a — i^^SSZS^SSS^ 

10 [0020] The present method emrts accessor functions, declarations and other data structure informatS, after deter 
sTuZ! I- ^ Conventional presentation of the data structure members. Z a ZZlTeZec daYa 
structure mformafon ,s cons,stent with changes in the internal class representation. This automate generaSon of con 

the 1 ZT tWe in '? rmati ° n minimiZeS Chan9SS 10 ,he VM that « w SalZ T^o 

» ^ Pmh^rtc nf T M f^ M Chan9e - TWS Pr ° VideS 3 Si9nificant lament over the pX art 

1 + ? k ^ mb ° d,ments of tne svstem °» *e present invention include a collection of class files a Java class oreloadar 
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distinct values of each type of member, 
amount of space required to store the values, 
the size of the value indices, and 
the number of occurrences of each member type. 



SZZL^"^? Perf0rmS 3 SeC ° nd paSS °" the class files and the in, ernal data structures to determine 
SroprSJ ZTnU:. t0 bS rePr6Sented ' COnve "^ a »V « — " * a value table entry, and then em's thTa" 

ESS , Th6 OUtPUt I" 68 com P a,ib,s with sim »^ files employed by conventional Java systems That is the ore 
££L2 Tv^T asSemblad or com P i,ed into -*« data and the header fi.es and sourcTf iles ^n be 
compiled with VM sources into VM object data. The VM and class obiect data ran .h 0n k„ ii C * .u 
manner into the executable VM for a particular Java environmlm 6 th ° convsntional 

BRIEF DESCRIPTION OF THE DRAWINGS 

ESS J2? hT' a " d ' eatUreS ° f embodiments - ^e invention will be more readily apparent from the fol- 

lowing detailed descr.pt.on and appended claims when taken in conjunction with the drawings, in whicn: 

^ FIG. 1 illustrates the class file format common to the prior art and embodiments of the present invention; 

i^rZL* b,<>Ck dia9ram ° f VM intema ' S,rUCtUreS USed in ,he pri ° r art to encode »«-hod and field 

Tn RG. B 2A; StratSS ** "** define ,he ,om * of VM internal data structures shown 

45 

p'sen™ 



FIG. 4 is a block diagram of a execution engine in the distributed computer system of FIG.1 in which the oreloaded 
classes generated by the class preloader of FIG. 3 are loaded into ROM; preloaded 

FIG. 5 is a flow diagram illustrating the processing components used to produce the preloaded executable module; 
eTexecJa^ 

FIG. 7 A illustrates the organization of the updated header file 614 of FIG. 6; 
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FIG. 7B illustrates the organization of the value table 616 of FIG. 6; 

FIG 8A illustrates the organization of same member occurrences and values after allocation in the execution 
s engine ROM 208 in accordance with embodiments of the present invention, anoca ™ « the execution 

SS ~ S^KSSt - same member °~ urrences after a,,ocati - * - «i- ™ 

» imttforCesem^ °' 3 * Ve * 

FIG. 9B illustrates the organization of the data structure instance from FIG. 9A generated by the prior art; 

pSoa^ VaZT^d *" * *" to bUi ' d the intema ' *«■ s,ructuras — the 

FIG. 11 is a block diagram showing the mapping of a preloaded application into read-only memory and random 
access rnemory and mdicating the .oading of the portion of the methods and data mappedTnTc ^LSSSS 
memory by a static class initializer. «w»u imo ranoom-access 
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DESCRIPTION OF THE PREFERRED EMBODIMENT 

[0026] The method and system described herein are directed to a Java class preloader confiaured to outn.rt «™i~,h 
ed Java classes that are optimized for storage in the ROM of a target computed ^^To h^n ^t? P ^ 

22 j G Jr r th r x Tr engine fe ,ike,y to be a ^^^^^^^^ss 

that the Java class preloader be implemented in a separate computer, which shall be refem* to hercn L a seXer 

a ZZ 9 * 3 T' 911 ^ Pre,0aded C,3SSeS COU,d be t™sferred from the server toVsexeZ^en^Zln 
a vanety of ways (e.g., network connection, direct communication link or "sneaker nef transfer Trea^^m^ 

to a computer system w,th a server and an execution engine wherein the preloaded classes are generated bT S 

S^"£XE SEE,* the — en9ine ,or U8e h the VM The ~ 

[0027] Referring to FIG. 3, there is shown a distributed computer system 100 in which emhnriimante «f 
invention may be imp,emented. The computer system 100 has' one I ZZ^Ten^^^lZZZ 
server computers 1 04. In a preferred embodiment, each execution engine 102 is aZ^^e^T^Xll 
interne, 106. although other types of communication connections between the compute^ 104 iuS b <e 

CD^l^tT' d,reCt T mUniCatiQn ' ink ° r ,Sneaker net " tranS,er of readabte media such Ts floppy dSs or 
CDs). Preferabfc the server and execution engines are desktop computers, such as Sun workstations iSSSSS 

[0028] The server computer 104 typically includes one or more processors 112, a communications interface 116 * 
user interface 114, and memory 110. The memory 110 stores: communications interlace 116, a 

• an operating system 118; 

• TJllT^rT 0 * 1 ?™ mana9Sr Pr09ram ° r ° th8r ,ype ° f ne,work access Procedures 120 

• a compiler 122 for translating source code written in the Java programming language into a stream of bytecodes 

. a STr^ T""?^ inC,Udin9 009 ° f ^ S ° UrCe COde fi,es Containing Ja^a iu^cSde" ' 
«, T? ^ ? ^ Udin9 °" e ° f P^^ependent ch» files 130 and oTmore Cass 

l-branes 1 31 containing class files, each class file containing the data representing a particulars 
- a class preloader 132 that generates a se, of preloaded classes 148 fora particular conlguraL of L execution 

engine (the class preloader is sometimes referred to as a static class loader) execution 

" ^T^ 1 " . 1 34 th3t Pr0dUCaS a " ° bj9Ct fi ' e re P rese " tin 9 the class members, class data structures and memory 
storage indicators in a format that is recognizable for the linker- rnemory 

' ence^an? ** dS,ermining la * 0ut 1or a set of P-^ed classes and for resofving all symbolic refer- 

> one or more data files 146 for use by the server (including the preloaded classes 148) 



BNSOOCID: <EP 0943969A2_t_> 



5 



G 

EP 0 943 989 A2 

[0029] Note that the class file repository 1 28, class preloader 1 32, assembler 1 34 and linker 1 36 need not reside on 
the server 104, but can be on any computer whose output (e.g., files or messages representing the preloaded classes 
148) can be copied to the execution engine 102. 

[0030] Referring to FIG. 4 t an execution engine 102 can include one or more processors 202. a communications 
s interface 206, a user interface 204, a read-only memory 208 and a random access memory 21 0. The read-only memory 
208 stores program methods that have no unresolved references and program data that remains constant during 
program operation. In the preferred embodiment, methods and data stored in the ROM 208 include portions of Java 
applications 212 and the execution engine's support procedures. These support procedures include an operating sys- 
tem 213, network access procedures 214, preloaded classes 232 and internal data structures 1200 (FIG. 2) used by 
10 the preloaded classes 232. 

[0031] The random access memory 210 stores: 

• a second portion of the Java applications 215 and support procedures 216, 217 that contain methods having 
unresolved references and data that is altered during the application's execution; and 
is • one or more data files 228 that the execution engine may utilize during its processing. 

[0032] Referring to FIG. 5, there is shown a flow chart illustrating the sequence of steps used to produce a preloaded 
executable module. It should be noted that the method and system descrfoed herein pertains to preloading a Java 
application and other support procedures. Any Java application, or any other set of methods that are normally linked 

20 a t run time could be preloaded using the method and system described herein. 

[0033] The source code 1 26 for each class that comprises the Java application is compiled by the compiler 1 22 into 
a class file 130, which is a platform-independent representation of the class. As described in reference to FIG. 1, the 
class file contains field and method tables, each method's bytecodes, constant data and other information. Alternatively, 
the class files corresponding to the application can already reside in one or more class libraries 131 . The entire set of 

2S class files 128 that constitute an application to be preloaded are transmitted to the class preloader 1 32. 

[0034] The job of the class preloader is to generate the preloaded classes 148 for an execution engine 102 (FIG. 4). 
The preloaded classes 148 include the class block 1202, method blocks 1204, field blocks 1214 and constant pool 
1224 described in reference to FIG. 2. Among other things, the class preloader 132 determines which methods and 
fields associated with each class 1 30 can be stored in a read-only memory 208 and which must be stored in a random 

30 access memory device 210. For example, methods that invoke Java interfaces or utilize non-static instance variables 
need to reside in random access memory. This is because the bytecodes that implement interfaces are determined at 
runtime and non-static instance variables are altered for each instantiation of the associated class. 
[0035] The class preloader 1 32 also performs a number of optimizations in orderto produce a more compact internal 
representation of the executable code when that code is loaded into the execution engine ROM 208. For example, the 

35 class preloader 132 combines the constant pools associated with each class to eliminate redundancy in the internal 
representation of the class constant pool 310. In accordance with the present embodiment, the class preloader 132 
also modifies the internal data structures 1200 (FIG. 2A) to take up less space in the ROM of the execution engine 
102. It is an advantage of the present embodiment that this data structure optimization largely frees the internal rep- 
resentation from inefficient standard data structure formats 1200 used in the prior art. 

40 [0036] The preloaded classes 1 48 are transmitted to an assembler or compiler 1 34 that produces an object module 
304 having the required format for the linker 1 36 to map the data into the appropriate address spaces. Preferably, there 
will be two address spaces, one for a random access memory device and a second for read-only memory device. The 
object module 304 is then transmitted to the linker 1 36 which generates a memory layout for the classes in the appli- 
cation. Once the memory layout is determined, the linker 1 36 resolves all symbolic references and replaces them with 

45 direct addresses. The memory layout is partitioned into the two address spaces. The methods and fields that were 
flagged for read-only memory are included in the first address space and the methods and data that were flagged as 
requiring storage in a random access memory are included in a second address space. The output from the linker 136 
is a preloaded executable module 306 containing the methods and data for these two address spaces. The processing 
flow of the present embodiment is now described with reference to FIG. 6. 

so [0037] Referring to FIG. 6, there is shown a data flow diagram of the process employed by the present embodiment 
to reduce the memory footpnnt of internal data structures used by the VM. As already described in reference to FIG. 
3, the class preloader 132 generates a set of plattorm-specific preloaded classes 148 from the class files 128. The 
preloaded classes 148 are data structure declarations that can be declared in assembler source or by a high level 
language. An assembler 134 or compiler 122 then converts these data declarations to object data 622. The class 

55 preloader 132 also determines the most efficient representation of the internal data structures 1200 composing the 
preloaded classes 232. 

[0038] In the preferred embodiment a member of the internal data structures can be represented in one of two ways: 
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1) as a generic memory word (e.g.. of 32 bits) that is the value of the member- or 

2) as an index to a table of distinct values that can be taken by the member for each occurrence of the member. 

Srt.r^if re P res f" tetion is * he only representation used in the data structures emitted by the prior art class 
preloader. Th.s represer.tet.on can be very inefficient when a particular member for which hundreds or thousands of 

ZThT eX,S i 3 ,6W Va,U6S SUCh 3 Si,Uati0n ' a ,u " widtn ™™»V word (e.g.. 32 b^Se) is 

allocated for each of the occurrences, taking up as many as thousands of words of scarce storage in the ROM 208 

eZJSS 3 It* dW r nt K a ' UeS ^ St0red " The S6COnd re P^^ation. which is employed b7the preSni 
embod ment, solves th* problem by generating a value table 616 to hold the definite values of such a member and 
t 9 ^ e TS° r -rl a ot the member an index of only as many bits as is necessary to address all of the value 

2S ll?TL^J^- 7 r6Sent f °" is ^"tageous when the memoiy that would be allocated for the indices 
^^^^ V^^. mmt0r tVPe ' S Sma " er th3n th ° a,toCated memor y ret > uired for 9 eneric r^en- 

embodimen1 determines how to encode the member — s « > da - 

[0040] Once the determination of howto represent the members is made, the class preloader 132 outputs for each 
ZSf^c ;r presen,ed * e tormat updated header information 614 (inc.uding modSed member 

Z Z ^ ?£? . ."? ,onmat,on 61 4 and va,ue 61 6. which are generated as source code, are compiled 
by the comp.ler 122 along wth the virtual machine sources 618 that define the virtual machine to be executed? the 
execution eng.ne V 32. The , linker 1 36 links the resuming object data 620 and the object data 622 to generate the^eToao* 
ed executab e module 306, which can be loaded into the execution engine 102. One by-product of the presentTm 
bodimen ,s that, whenever new classes or members are to be incorporated in the preloaded classes 148. a new VM 
246 must be generated. Th.s is because the corresponding header information 614 and value tables 616 must be 
comp.led wi* the VM sources 618. However, because the present embodiment automatically generates the header 

to ThTvlTco^ ™ fi "£ h Va 'T 6 JSir[ ° f ClaSSeS ■ 9 enerati "9 the new VM «*V>™ "° or minima, changes 
nfi^^L ^! T£ ,S ^ eoause the VM 246 alwavs makes of the accessor functions that are part of the header 
.nforrnajon 614. Thus, the present embodiment is able to generate an efficient representation of date structure mem- 
bers while facilitating generation of the VM. 

5£ 1 L,~ e o? a h S Pre,0ader 1 32 i ab ' e ,0 . 9enerate the eff,Cient index * able ™«*e' representation because all pos- 

nullr 5 Z b6rS T * 3 feSUlt ' thS nUmbSr °' bftS needed tor each inde * is a,so k »°wn. The 

«.1T nop TOCUrrences of ea( f members ,s a,so known. Moreover, the preferred embodiment presumes that the class 
files 128 represent the complete set of classes that are to be preloaded into the target execution eng ne Vol ThE 

t^TST 15 "I?** 1 ' aPP,iCab ,' e t0 eXeCUti0n en9in8S 102 mat afe amal handhe " computers. wh ,?h are unlikely 
to have the computing power and/or communications bandwidth to download classes on the fly in the ccwentS 

SZ. if number K, of : ndices and va,ues are ^ and *-» ,here * n ° possibility^ iS„7SS3 

member, or classes, rt >s possible for the class preloader 1 32 to arrange the indices to have an optimally compact 
near-optimal arrangement when altocated by the execution engine 102. The class preloader 132 achieveHTlevel 
of compaction by selecting the order of the indices in the updated header information 614 acmeves ,evel 

[C042] Referring to FIGS. 7A and 7B, there is illustrated the organization of the updated header information 614 and 

eratSb! S I 616 T^S" 6 " 0 eXamP ' eS * ^ StrUCtUra ^ 6 ^ les «^puts gen 

^ teSS pretoader 1 32 corresponding to the data structure declaration 1 230.N from FIG 2B 

S^L T heUpdatedh ! aderfi,e614showninFIG 7Ainclud esasetofdatastructuredeclarations702.eachofwhich 
can include, in any combination, updated member declarations 704 and un-updated member declarations 708 Each 

ZS££IVZ ^TV 02 co™** 0 "** to «• * tne — useSby the VM 246. The up^ted member 

declarator 704 are for date structure members that have been modified by the class preloader 132 as index/tebTe 
members and the un-updated members 706 are for data structure members that theclass preloader iSSSSSS 

ZLnsT a Pr Z7 e H 9ene H rk5al ^ E3Ch ** StfUC,Ure d8C,ara,i0n 702 iS associated witn u ^ed mJSr^bTSS 
1^1^.^' upda,ed me ^ raccessor 'unctions 71 Oand un-updated member accessor functions 712. Each updated 
member table declaration 708 is associated with a corresponding value table 616 and declares that table in the a P - 

P iTind!Sr m,n9 H 9Ua9e t " UPdated membSr aCC6SSOr ,UnCtion 71 0 defines accessor function for updated 
(..e., mdexAable) members us,ng the table name defined in the respective updated member table declaration 708 The 
^updated member accessor functions 712 are unchanged from those generated by the conventional ^preto^er 

£0044] For example, FIG. 7A shows the updated header file information 614 for the data structure 1230 N (Struct T) 
from FIG. 2B. The example assumes that the class preloader 1 32 determined that: 

1) member! has 400 values and is best represented as an index/table member, 

2) member2 is best represented conventionally. 
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3) members has 200 values and is best represented as an index/table member, 

4) member* has 1500 values and is best represented as an index/table member, and 

5) members is best represented conventionally. 

r00451 Consequently, the class preloader 1 32 has generated a modified "struct T declaration 704 wherein membert 
is represented as a 9-bit integer index m1_idx (9-bits being enough to access 200 values), members is represented 
as an 8-bit integer index m3_idx (enough to access 400 values) and membert is represented as an 1 1 -bit integer index 
m4 J dx (enough to access 1 500 values). The other members, member and members, axe left unmodified as generic 
members of type mtype2 and mtypeS, respectively . 
r00461 The class preloader 1 32 has also generated an updated member table declaration 708 for member J showing 
that the memberl values are stored in a value table (member1_value[]) of type memberl. The member1_value table 
is declared as an external variable (extern), which tells the compiler 1 22 that the actual values of the table are defined 
in another file, in this case the value tables file 616. Similar updated member table declarations 708 are generated for 

r004^^The d ac7e^ortunction 710 for the updated memberl is correspondingly modified so that each time the cor- 
responding accessor function, memberl of (T), is invoked the VM 246 that accesses the preloaded methods uses the 
memberl value (i.e., the 9-bit m1_idx) as an index into the member1_value table. The accessor functions 710 for the 
updated members and member 4 are modified in similar fashion. 

[00481 Referring to FIG. 7B, there is shown a representation of the value tables 616, including a table 722.1 that 
defines the definite values that can be taken by the member 1_value table declared in the header file 614. In this case, 
the member1_value table is defined as a constant array ("const mtypel member1_value[n consisting of 400 values, 
val 1 ,. . . val 400. Similar representations of the value tables for members and member4 are also provided (e.g.. in the 
member 3 and 4 tables 722.3, 722.4). 

[0049] Referring to FIG SA. there is shown an illustration of the manner in which the internal data structures(specif- 
ically. the member occurrences 802 and value table 806 for a single member type) of the present embodiment are 
orqanized in the execution engine ROM 208. Each of the occurrences represents one occurrence in a preloaded class 
of the same member 802 and the data structure type 805 that encompasses it (the data structure type 805 is likely to 
include multiple members - e.g., see FIG. 2B). Assuming that a particular member has N distinct values 808 which 
are stored in the value table 806, each of the M occurrences 802 of that member is allocated as an index 804 of width 
(\toaJN)\ +1) bits to the entry of the value table 806 that holds the member's value. For example, each of the occurrences 
802 1 and 802 6 is an index to the table entry 806.N. This entry 806.N stores the definite value 808.N associated wrth 
those member occurrences. Thus, the total memory usage of this model is M^log^N^D * value_table_sizebAs per 
member. 

[O0S0] Referring to FIG. BB, there is shown an illustration of the manner in which the prior art organizes occurrences 
852 in the execution engine ROM 208 of a particular member. Each of the occurrences 852 represents one occurrence 
in a preloaded class of a particular member. Each of the M occurrences 852 of that member is allocated as a full-width 
memory word that stores the value 854 of the member for that occurrence (i.e.. each of these occurrences are repre- 
sented in the first format referred to above.) Thus, the total memory usage of this model is M*32 bits (assuming 32-bit 
memory words) As a result, the present embodiment saves memory allocated for a particular member in the data 
structures when Af*(1tog^/v;/+ ^ + value_table_size is less than M'memory_word_size (e.g., M'32). As in the example 
of FIG 8A the fields 802 are likely to be just one element in a data structure declaration. 

[0051] Referring to FIG. 9A. there is shown an example of how the class preloader 1 32 of the present embodiment 
efficiently stores in the execution engine ROM 208 all of the members 802 of a particular data structure 902 (e.g., the 
members of the structure. Struct T 1230.N, FIG. 2B). Generally, the present embodiment packs the stored values (i. 
e the indices 804) so that they occupy as much of a fixed length memory word as possible. In the illustrated situation, 
the memory words are 32 bits wide, but the present embodiment is applicable to memory words of any length. In the 
example shown in FIG. 9A, the 9-bit. 8-bit and 11 -bit members ml, m3 and m4 from Struct T 902 are packed into a 
single 32-bit memory word, values of the members m2, m5, which are represented conventionally (e.g., as 32-bit 
values) are stored in respective 32-bit general variables following the first word. In the preferred embodiment, these 
conventionally-represented members must be aligned on word boundaries (e.g., every 32 bits). There is no such re- 
quirement for the modified members. Therefore, for each data structure instance there are only 4-bits of unused space 
904 between the fourth member m4 and the first general variable m2 The class preloader 132 aims to pack the mem- 
bers of an internal data structure into memory words as efficiently as possible given any combination of member rep- 
resentations and member sizes. _ _ 
[0052] Referring to FIG 9B, there is shown a diagram illustrating the format of the same data structure Struct T as 
stored by the prior art class preloader. Note that, in this system, the data structure requires 5 words to store the 5 
members Thus the pnor art is far less efficient than embodiments of the present invention (which only need 3 words 
to store the same data structure information) Embodiments of the method of the present invention are now descnbed 
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in reference to FIG. 1 0. 

[0053] This arrangement presents noproblems to the preloaded classes' use of the accessor functions as the different 
memory locations of the indices 804 are resolved by the compiler 122 and the indices themselves store the index of 
their associated value 808. 

[0054] Referring to FIG. 1 0, there is shown a flow diagram of an embodiment of the method of the present invention 
implemented in the class preloader 1 32. The present method is implemented in two passes, which include an account- 
ing pass (represented by the box labeled 1104) and a data structure declaration generation pass (represented by the 
rest of the steps). As the first accounting step (performed for all internal data structures), the preloader 132 identifies 
all member types of an internal data structure (1106). For example, referring to FIG. 2B, the five members of Struct T 
are that data structure's member types. For each member type, the class preloader 132 then performs the following 
processing: a 

Identify M occurrences of the member type (1108). 

Identify N values of the M occurrences (1110). 

Determine the memory space needed to store each value (1112). 

Determine the memory space needed to store an index that can address the N values (the index must be at least 
\logg(N)\+1 bits) (1114); 

Determine the size of the conventional representation of the member occurrences (11 16). 

[0055] This processing is performed on all members of all internal data structures before proceeding with the steps 
starting with box 1 1 18. This order of processing is preferable as the accounting statistics generated by the procedures 
in the box 1104 are used by the subsequent second pass steps. Typically, the accounting statistics are stored tempo- 
rarily for use in the second pass. ^ 
[0056] Once all of the statistics have been generated, the class preloader 1 32 computes for each member type: 

the memory space (LHS) required by the conventional representation of the member occurrences (1120) and 
the memory space (RHS) required by the novel representation of each member occurrence as an index to'a value 
t3bl© (1122). 

[0057] The class preloader 132 computes the LHS value in step 1120 as follows: 

LHS = (size of the conventional representation) x no. of occurrences 
(size of the conventional representation) x M bits. 



40 



45 



[0058] The class preloader 132 computes the RHS value in step 1122 as follows: 

RHS = (size of the member value) x no. of occurrences + size of the value table 
(size of the member value) x M + M x (|log 2 (N)|+ 1 ) bits. 

[0059] If the RHS is smaller than the LHS (1124-Y), the class preloader 1 32 represents that member type as a value 
table and indices (1 126). If the RHS is not smaller than the LHS (11 24-N). the class preloader will represent that member 
type conventionally (1128). 

so P ^Led h (1l2t S N) Prel0ader fepeatS th8Steps 1120, 1122 ' 1124 ' 1126 ' 1128 wn,le otner members remain to be 
[0061] Once each member has been processed (1 1 24-Y), the class preloader 1 32 performs a data structure decla- 
ration generation procedure 1130. In this procedure, tor each data structure the class preloader 132 determines the 
opt.mal ordenng of the data structure members (1 1 32). The ordering process and its considerations have already been 
described ,n reference to FIG. 9A. The class preloader 132 then generates the member header information 614 and 
values table 616 1 in accordance with the optimal ordering (1134). The generation of the header information 614 and 
member values 616 has already been described in reference to FIGS. 7A and 7B. 

[0062] Referring to Fig. 1 1 . the preloaded executable module and boot time initiator 1 320 are permanently stored in 
the read-only memory of an execution engine computer. Each time the execution engine computer is powered on or 
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rebooted, the boot time initiator 1 320 is automatically executed. Among other tasks, the boot time initiator copies all 
methods and data that must be resident in random access memory during execution to the random access memory 
locations assigned to them by the linker. 

[0063] Although the method and system described herein have been described with reference to the Java program- 
s ming language the present invention is applicable to computer systems using other object-oriented classes that utilize 
dynamic runtime loading of classes. 

[0064] Further, embodiments of the present invention are amenable for execution on various types of executable 
mediums other than a memory device such as a random access memory. Other types of executable mediums can be 
used, such as, but not limited to, a computer-readable storage medium, which can be any memory device, compact 
io disc, or floppy disk. 

[0065] The aforementioned system and method have been described with respect to executing a generic Java ap- 
plication and are applicable to any Java application. For example, the embodiments of the present invention could be 
employed to preload classes used by a personal information manager coded in Java intended to run on a handheld 
computer. Moreover, the Java application need not be run in a distributed environment, it can run in stand-alone mode 
is executing in a execution engine or server computer without importing new classes from external systems. 

[0066] While embodiments of the present invention have been described with reference to a few specific embodi- 
ments, the description is illustrative of the invention and is not to be construed as limiting the invention. \/arious mod- 
ifications may occur to those skilled in the art without departing from the scope of the invention as defined by the 
appended claims. 

20 

Claims 

1 . A method for reducing memory footprint of preloaded classes to be incorporated into a runtime environment, com- 
25 prising the steps of: 

determining types of data structures represented in one or more class files used to define a plurality of preload- 
ed classes, each of the data structure types including one or more members; 
determining distinct values that can be taken by each of the members; 
30 storing each of the values for at least a subset of the members selected to reduce the size of corresponding 

internal data structures composing the preloaded classes; 

generating a set of value indices for addressing stored values stored in the storing step; and 
generating accessor functions and member declarations that enable the runtime environment to use the se- 
lected members represented as the stored values and the set of value indices. 

35 

2. A system for reducing the memory footprint of preloaded classes to be incorporated into a runtime environment, 
comprising: 

a set of class files; and 

40 a class preloader configured to generate from the class files a set of preloaded classes and a plurality of 

internal data structure declarations configured to minimize size of the preloaded classes when allocated in 
memory; 

the class preloader being configured to generate the internal data structure declarations so that each of a set 
of selected data structure members are represented as an index to a storage structure holding distinct values 
45 of the selected data structure member. 

3. A computer program product for use in a computer system for reducing the memory footprint of preloaded classes 
to be incorporated into a runtime environment executing on an execution engine, the computer program product 
including a computer readable storage medium and a computer program mechanism embedded therein, the com- 

so puter program mechanism comprising: 

a class preloader configured to generate from a set of class fifes the preloaded classes and a plurality of 
internal data structure declarations configured to minimize size of the preloaded classes when allocated in 
memory of the execution engine; 
ss the class preloader being configured to generate the internal data structure declarations so that each of a set 

of selected data structure members are represented as an index to a storage structure holding distinct values 
of the selected data structure member. 
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4. A runtime environment built from a collection of preloaded classes defined by one or more internal data structure 
types, each including one or more members, the runtime environment comprising: 

a storage structure holding distinct values that can be taken by at least a subset of the members; and 
an index to a storage structure entry holding the distinct value of a respective member of the subset of the 
members serving as each occurrence of the respective member with the distinct value; 
such that the runtime environment determines when necessary the distinct value of the respective member 
by retrieving contents of the storage structure at a location defined by the index. 

5. The runtime environment of claim 4, wherein all of the distinct values are known and the index to the storage 
structure entry is implemented using fewest bits able to index all of the distinct values associated with the respective 
member. 

6. A method for loading an execution engine with preloaded classes to be incorporated into a runtime environment 
to be executed on the execution engine, comprising: downloading into the execution engine the preloaded classes, 
including a plurality ol internal data structure declarations composing the preloaded classes configured so that 
each of a set of selected data structure members is represented as an index to a stored distinct value of the 
selected data structure member, the set being selected to minimize size of the preloaded classes when allocated 
in memory of the execution engine. 

7. The method of claim 6, wherein the preloaded classes are downloaded over the Internet. 

8. The method of claim 6, further comprising: allocating the preloaded classes in the memory of the execution engine. 

25 9. A method for generating and loading into a client preloaded classes to be incorporated into a runtime environment 
to be executed on the client, comprising: 

generating in a server the preloaded classes, including a plurality of internal data structure declarations com- 
posing the preloaded classes configured so that each of a set of selected data structure members is repre- 
sented as an index to a storage structure holding distinct values of the selected data structure member, the 
set being selected to minimize size of the preloaded classes when allocated in memory of the client and 
downloading into the client the preloaded classes. 

10. A method for reducing memory footprint of preloaded classes to be incorporated into a runtime environment com- 
35 prising the steps of: 

determining distinct values that can be taken by members of internal data structures composing the preloaded 
classes; 

storing each of the values for at least a subset of the members selected to reduce the size of the internal data 
40 structures; and 

replacing each occurrence of a subset member with an index to the value of that occurrence, enabling the 
value of that occurrence to be retrieved via the index. 

11. A system for reducing the memory footprint of preloaded classes to be incorporated into a runtime environment 
45 comprising: 

a class preloader configured to generate a set of internal data structure declarations configured to minimize 
size of the preloaded classes when allocated in memory, the internal data structure declarations declaring 
internal data structures composing the preloaded classes; 
50 tne ctess Preloader being configured to generate the internal data structure declarations so that each of a set 

of selected data structure members is represented as an index to a storage structure holding distinct values 
of the selected data structure member. 
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